爻枢 Code

主题

怎么向 AI 提需求 ​

同一句话，说法不同，第一版质量差很多。本页讲怎么把需求说清楚——不用写文档，几句话说对地方。

一条铁律：说业务，不说实现 ​

您负责「要什么」，它负责「怎么做」。把业务目标说清楚，技术选型、目录结构、依赖版本交给它定。

说法效果
「帮我做一个设备管理系统：设备台账、点检计划、维修工单、备件库存」✅ 好——业务清楚，边界明确，它来定技术栈
「用 Vue3 + Pinia + Element Plus 帮我写一个设备管理的页面，组件要拆分」⚠️ 可以，但您替它做了技术决策——除非团队规范就是这么定的
「帮我做个系统」❌ 太空——它会反问好几轮才能开工

例外：团队有既定技术栈、必须兼容老系统时，第一句话就说明白：「技术栈用我们现有的 React 18 + AntD，别引入新框架」。

说清三样：给谁用 · 要什么 · 边界在哪 ​

  1. 给谁用：内部员工？客户？管理员 + 普通用户两种角色？——决定权限设计和界面深浅
  2. 要什么（核心功能清单）：列 3~6 条「必须有」的功能，一条一行
  3. 边界在哪：什么先不做、什么不用管——划定边界能省掉大半无效沟通
text
给我们车间做一个设备点检小系统：
- 给巡检工用，手机上操作，就一个角色
- 设备清单、按周排点检计划、扫码打卡记录、超期提醒
- 不用管采购和库存，一期不做统计报表

这样一句话，第一版就能跑。

迭代式提需求：先跑起来，再逐步改 ​

不要试图第一句话把所有细节说完。更好的节奏：

text
第 1 轮：把核心功能跑起来（上面那句）
第 2 轮：跑起来后看着页面提：「列表加个按车间筛选」
第 3 轮：「点检记录加一张照片，巡检工要拍照留证」
第 4 轮：「提醒改成企业微信推送」

每一轮都在看得见的东西上提修改——比开写前凭空想需求准得多。它改完会自己验证再给您看。

把上下文一起给上 ​

您有的怎么给
参考系统 / 竞品截图拖进对话框——「照这个感觉做」
旧版代码 / 相关模块指给它：「参考 项目/src/modules/order 的写法」
接口文档 / 表结构拖进来或贴关键片段
口头想法直接说，说不清就让它先出两版方案选

素材给法详见怎么把需求与素材喂给 AI。

描述问题的模板：现象 + 预期 + 怎么复现 ​

报 Bug 或改行为时，这三段式最省轮次：

text
点检打卡后列表没刷新（现象），
应该打卡完马上能看到新记录（预期），
打卡一次就能复现（复现步骤）。

比「列表有点问题」快一个量级。

它听不懂时怎么办 ​

情况您做
它理解偏了马上打断（点停止），一句话纠正——比做完再改省一半时间
它问的选择题看不懂点卡上「说人话」看大白话版；或选带「推荐」的先跑起来
改了几轮还不对停下来重新对齐：「先别改了，我再说一遍我要的是……」
需求自己也还没想清让它先出方案：「这个你给两个方案，各带优缺点，我选一个」

常见误区 ​

误区更好的做法
一句话塞十个功能核心功能先跑，其余排进后续轮次
「做得好看点」给参照物：「照××App 的风格」或「简洁的后台风，别太花」——有锚点才不跑偏
频繁换目标一轮改一类问题（先功能后样式）；来回跳会让它前后推翻
怕说错不敢开口说错没关系——每一轮都是可修正的，改动可回退（见改错了怎么回退）

延伸阅读 ​